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REMARKS 



Claims 1-44 are pending in the present application. Claims 1-44 stand rejected. Claims 1 
and 5 have been amended. Support for the amendment is found in the specification, no new 
matter has been added. Claims 2-4 and 6-44 remain unchanged. 

Claims 1-44 have been rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. 
Patent 6,058,389 (issued 2 May 2000) to Chandra et al. Applicants respectfully submit that "for 
anticipation under 35 U.S.C. §102, the reference must teach every aspect of the claimed 
invention either explicitly or impliedly. Any feature not directly taught must be inherently 
present." MPEP 706.02. 

1. Applicants submit that amended claim 1 is patentable over Chandra. Applicants further 
submit that Chandra teaches one information queue record per message for all consumers, 
whereas an element of amended claim 1 recites " history record for each consumer for each 
information record comprising data to be provided to each said consumer." In other words, a 
history record exists for each consumer, per message that the specific consumer is to access. For 
example, if message MSG1 were to be accessed by 12 consumers, there would be 12 history 
records - one record for each consumer for message MSG1. 

Chandra shows one information record for all consumers in the following passage. 

A queue table 200 holds a set of queues, and each queue table 200 is 
implemented as a database table within the relational database system 300. Each 
queue table 200 can contain multiple queues 202, 204 each having multiple queue 
messages 208. In one embodiment, a queue table 200 is structured as shown in FIG. 
2. Each row of the queue table 200 represents a message 208 in a queue 202, 204. 
Some of the columns in a queue table 200 are meta-data describing a queue 202, 
204. In one embodiment, each row of the queue table 200 has the following 
columns: 



Column 



Contents 



QUEUE 

MSG_ID 

CORR_ID 

MSGJPRIORITY 
MSG STATE 



Queue name 
Message identifier 

User-provided correlation identifier 

Message priority 

State of the message (READY to be 
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EXPIRATION ] 
TIME MANAGER INFO 



DELAY 



processed, DELAYED , PROCESSED, or EXPIRED) 
Time after which the message will be 
ready to be processed 
Message expiration time in seconds 



USER DATA 



DEQ_TXN_ID 



DEQ_USER_ID 



L0CAL_ORDER_N0 

CHAINJSTO 

DSCN 

CSCN 

ENQ_TIME 

ENQ_USER_ID 



ENQ_TXN_ID 
DEQ_TIME 



Date used by time manager process to 

monitor messages 

Local order number of message 

Chain number of message 

Dependent transaction number 

Commit transaction number 

Original enqueue time 

User identifier for the user who 

enqueued the message 

Current transaction identifier 

Time when the message was 

dequeued 

Transaction which performed the 
dequeue 

User id of the user who dequeued the 
message 

User data for use by an application or 
process 



Column 7, lines 4-40, 45-47 (emphasis added). 

Note that the single information record includes a MSG_ID to identify the message, a 
ENQ_USER_ID to identify the user who enqueued the message, and an DEQ_USER_ID to 
identify the user who dequeued the message. However, this one single record includes both the 
ENQJJSERID and the DEQ_USER_JD, not separate records for each consumer. Further, even 
if there were two separate information records for one message for each of the ENQ_USER_ID 
and the DEQ_USER_DD, the two records would only identify two consumers, the ones who 
enqueued or dequeud the message, not each and every user who is to access, or has accessed, the 
message. 

Applicants further submit that the CORRJD does not provide a method to identify a 
consumer of the message. For example, Chandra discloses "The correlation identifier is a value 
that identifies a message ... Column 13, lines 31-32. Further, Chandra discloses: "In step 
950, the process reads all the parameter values. In step 952, the process evaluates whether the 
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Message Identifier value or the Correlation Identifier value is provided. If a valid Message 
Identifier exists , then in step 954 the process selects a message from the named queue based 
upon the Message Identifier. If a valid Correlation Identifier exists, then in step 956 the process 
selects a message from the named queue based upon the Correlation Identifier." Column 18, 
lines 37-44, Figure 9B, elements 950 - 956. Therefore, Chandra does not disclose amended 
claim 1 as recited: 

A method for managing information to be accessed by multiple consumers, said 
information comprising one or more information records, said information records 
to be accessed by said multiple consumers in a specified order, each said 
information record comprising data to be accessed by a consumer, said method 
comprising: providing said data of an information record to a consumer; and 
updating a history table, said history table comprising a history record for each 
consumer for each information record comprising data to be provided to each said 
consumer, wherein each said history record comprising a message state field a, 
said updating comprising setting said message state field in a history record 
corresponding to said consumer to indicate said consumer accessed said data. 
Amended claim 1 (emphasis added). 



Claims 2-12 depend on claim 1 and are patentable over Chandra for at least these reasons. 



2. As per claim 13 the Office action states on page 7, lines 1-13 that Chandra discloses the 

elements of claim 13. However, Chandra discloses: 

A queue table 200 holds a set of queues, and each queue table 200 is 
implemented as a database table within the relational database system 300. Each 
queue table 200 can contain multiple queues 202, 204 each having multiple queue 
messages 208. In one embodiment, a queue table 200 is structured as shown in 
FIG. 2. Each row of the queue table 200 represents a message 208 in a queue 202, 
204. Some of the columns in a queue table 200 are meta-data describing a queue 

202, 204 DEQ__USER_ID User id of the user who dequeues the message 

Column 7, lines 4-12, and 40. 

Chandra further discloses: 

Transactions can create messaging using ENQUEUE operation and consume 
messages by using a DEQUEUE operation. Messages are selected for consumption 
based upon the control information stored with the message. 
Column 6, lines 60-63. 
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Applicants respectfully submit that the queue table of Chandra is used to read on both the 
information queue and a table separated from said information queue . For example, the Office 
action states "An information queue (queue table )" and "A table ( each queue table) separated 
from said information queue" on page 7, lines 3, 7 (emphasis added). 

Applicants further submit that Chandra teaches only one information record per message. 

For example Chandra discloses "An application can specify that messages shall be retained in a 

queue after consumption. . . . The system stores information about the history of each message, 

... ." Column 1 0, lines 28-29, 3 1 -32 (emphasis added). A message that is "retained in a queue" 

indicates it stays within the same container. Further Chandra discloses "Still another advantage 

of the disclosed system is coordinated recovery. According to the invention , a single transaction 

log is maintained ." Column 36, lines 23-25 (emphasis added). As Chandra clearly teaches one 

table for both information record and history, Chandra does not disclose claim 13 as recited: " 

A system for the delivery of information to multiple consumers, said system 
comprising: an information queue comprising one or more information queue 
records, each said information queue records comprising information to the 
accessed by one or more consumers; and a table separate from said information 
queue comprising one or more records, each said table record comprising an 
identification of said information in an information queue record each said table 
record further comprising a consumer identification field comprising an 
identification of one of said one or more consumers. 
Claim 13 (emphasis added). 

Claims 14-20, and 27 depend on claim 13 and are patentable over Chandra for at least the 
above reasons. 

3. Claim 21 is substantially similar to claim 13 and is patentable over Chandra for at least 
the same reasons as presented for claim 13. Claims 22 depends on claim 21 and is patentable 
over Chandra for at least the same reasons. 

4. Per claims 23, 31, and 38 the Office action states: 

The applicant argues that "Chandra does not disclose, teach, or suggest a 
method comprising [indicating] in a second location that said first consumer has 
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accessed said first piece of information and indicating in a third location that said 
second consumer has accessed said first piece of information." 

The examiner respectfully disagrees with the above argument. Chandra 
suggests "it is preferable for the Queue table to maintain a reference count of the 
applications that have a pointer to a particular message from the index, that is, 
applications for which message is in the current view. ... When the reference count 
reaches zero, the message is either deleted or archived." (col. 20, lines 41-49). This 
suggests that the second application access the message according to the pointer 
wherein the pointer is the reference location of the message wherein the reference 
pointer is also the third location for the second application to be accessed. 
Office action dated 23 March 2004, page 4, line 19 through page 5, line 8. 

The Office action correctly states "This suggests that the second application access the 

message according to the pointer wherein the pointer is the reference location of the message 

wherein the reference pointer is also the third location for the second application to be accessed." 

In other words, the single pointer is the reference location for both the second application and the 

third application. However, applicants submit that a single pointer as a reference location for 

both the second and third application is not in the claimed limitations. An element of the claim 

recites " indicating in a second location that said first consumer has accessed said first piece of 

information; providing access to said first piece of information to a second consumer of said 

multiple consumers; and indicating in a third location that said second consumer has accessed 

said first piece of information." However, Chandra teaches: 

In this embodiment, it is preferable for the Queue Table to maintain a reference 
count of the applications that have a pointer to a particular message from the index, 
that is, applications for which a message is within the current view. When a 
message is dequeued by an application, the corresponding index entry is deleted 
from the queue table index and the reference count of the message in the queue 
table is decremented. When the reference count reaches zero, the message is either 
deleted or archived. 
Column 20, lines 41-49. 

Applicants submit that Chandra discloses a single reference counter for each message that 
is decremented each time a consumer dequeues the message. For example, Chandra discloses 
"When a message is dequeued by an application, the corresponding index entry is deleted from 
the queue table index and the reference count of the message in the queue table is decremented." 
in column 20, lines 44-47. However, this single reference counter does not teach a second 
location and a third location, or more specifically, " indicating in a second location that said first 
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consumer has accessed said first piece of information; providing access to said first piece of 
information to a second consumer of said multiple consumers; and indicating in a third location 
that said second consumer has accessed said first piece of information." as recited in an element 
of claims 23, 31, and 38. 

Claims 24-30, 32-36, and 39-44 depend from claims 23, 31, and 38 respectively, and are 
patentable over Chandra for at least the same reasons as claims 23, 31, and 38. 

In summary, Applicants submit that Chandra does not disclose the elements of claims 1- 
44. Anticipation under 35 U.S.C. §102 requires the reference to teach every aspect of the 
claimed invention. As such, applicants respectfully submit that Chandra cannot preclude 
patentability of claims 1-44 under 35 U.S.C. §102. 
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CONCLUSION 



On the basis of the above amendment and remarks, reconsideration and allowance of the claims is 
believed to be warranted and such action is respectfully requested. If the Examiner has any questions or 
comments, the Examiner is respectfully requested to contact the undersigned at the number listed below. 

Respectfully submitted, 
Bingham McCutchen LLP 



Dated: May 26, 2004 



Three Embarcadero Center, Suite 1800 
San Francisco, CA 941 1 1-4067 
Telephone: (650)849-4904 
Telefax: (650)849-4800 



By. (^^^MjJ^ 

JanetDTchance 



Reg. No. 55,048 
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